home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1445 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB
  1. From: itschere@techfak.uni-bielefeld.de
  2. Subject: Re: Domain X
  3. Date: Tue, 24 May 94 11:32:10 MET DST
  4. In-Reply-To: <m0q5RLV-0000ePC@sdf.lonestar.org>; from "Evan K. Langlois" at May 22, 94 11:10:00 pm
  5.  
  6.  Huhu!
  7.  
  8. > >  If you silently accept to force these users to buy the newest MultiTOS in
  9. > > order to be able to do something serious, you can also say: Go and get the
  10. > > newest hardware, otherwise you won't be able to something serious at all.
  11. >
  12. > I don't understand.  MultiTOS or the ROM GEM can run.  GEM programs run
  13. > in MiNT or TOS domain (providing you are the super-user or are at the local
  14. > console, depending on how you want to protect things).  I'm NOt saying people
  15. > should buy MultiTOS as Domain X shouldn't allow GEM programs anyway.
  16.  
  17.  Ahhh. I've initially thought you wanted to make GEM secure. What remains, is
  18. the problem that once I want to give a user the right to start GEM, I
  19. therefore must grant him the right to switch back to DOM_MINT, and therefore
  20. must *really* trust him.
  21.  
  22.  Yet worse is that GEM/ROM doesn't work very well with memory protection and
  23. thus I would have to switch this off when wanting to allow GEM access, which
  24. is obviously a bad idea, since you can't do *that* per-process. That's the
  25. point where I was thinking buying MultiTOS would be the only solution.
  26.  
  27.  For me, it's easy: No GEM allowed at all. Others may disagree... :-)
  28.  
  29. > Protecting acess to XBIOS/BIOS/AES/VDI traps could be done by pointing
  30. > these traps into an internal MiNT routine when a program is run.  The first
  31. > call the program makes goes into MiNT.  If MiNT decides this program can
  32. > make the call legally, it simply assigns the pointer of the real trap
  33. > routines into that applications handler and falls through it. (...)
  34.  
  35.  In my eyes, the story is yet more simple: Since DOM_X programs are per
  36. definition not allowed to use BIOS/XBIOS/AES/VDI, just make these vektors
  37. point to a kill routine. Checks must only be done if a programs wants to
  38. switch back to != DOM_X. Once program is running under an old domain, trap
  39. vektors are inherited by all childs until it switches to DOM_X, in which
  40. case they're forced back to the kill routine.
  41.  
  42.  This should makes the checks both easier and shorter. :-)
  43.  
  44. > I've thought about this as well.  And I'm curious what everyone else thinks
  45. > about leaving this Unix-like domain to the 030s only.  Personally, I'd rather
  46. > not since I don't have an 030, but then again, I'm not the person that would
  47. > benefit much from the Unix domain anyway!!
  48.  
  49.  The problem is clear. It's just that under a pure 68000 it isn't what it's
  50. meant to be and what it promises... :-(
  51.  
  52.  Any ideas or votes?
  53.  
  54. ciao,
  55. TeSche
  56. -- 
  57. Torsten Scherer (Schiller, TeSche...)
  58. Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...
  59. | Use any of "finger itschere@129.70.131                |
  60. | Last updated: 14. April 1994                        |
  61.